Rewrite the privacy policy to cover accounts, saved places and analytics - #332

What this changes

Fixes #301 once a maintainer has confirmed it. The issue says every statement needs a maintainer's confirmation before merge, so please treat this as a draft for review: I wrote each line from the code and migrations, listed below, but I am not a lawyer and cannot vouch for the legal adequacy.

/legal/privacy was dated June 2026 and described only contributed places, GitHub usernames and page-view analytics. It now covers accounts, in plain language, with a new "Last updated: November 2026":

• Browsing without an account: no profile is kept; page views are counted by the analytics below.
• What is stored per account (and private to it): email and sign-in record; saved places (name, type, city, coordinates, address, note); a home location (coordinates, label); calendar events (title, date, category, notes); saved competitions plus a private calendar-feed token; first-run answers (graduation year, board, field, country, how you heard about us). Access is limited by row-level security so an account reads, changes and deletes only its own rows; the only public figure is how many accounts saved each competition.
• Public contributions are described separately from private saved places.
• Your location: "Near me" asks the browser and is used there, not sent to StudyMap.
• Who else sees what: Supabase (accounts and rows), Google (sign-in), Vercel Analytics and Umami (page views; Umami only on the live site and only when configured), MapTiler (map tiles: your browser requests them directly, so it sees your IP and the area you view), OpenStreetMap as data source. Sign-in sets session cookies; no ads or selling data.
• Password resets: only a hash of the email and a timestamp are kept for rate limiting, not linked to an account.
• Deleting and asking: you can edit or delete your own data in the app; to delete the account, email studentsuite3@gmail.com (the address on the About page). Deleting an account removes its rows because every per-user table references auth.users with on delete cascade.

Where each claim comes from

• Tables and columns: supabase/migrations/ (user_places, user_home, user_events, competition_saves, user_profiles including calendar_token, password_reset_attempts with email_hash). Row-level security policies are in the same files; competition_stats is the public count.
• Cascade delete: on delete cascade on auth.users(id) in the five per-user tables.
• Sign-in: src/app/login/login-form.tsx (signUp, signInWithPassword, Google OAuth, resetPasswordForEmail).
• Analytics: src/app/layout.tsx (@vercel/analytics), src/components/analytics.tsx (Umami, production only and only with a website id).
• Tiles: src/components/map/map-view.tsx (api.maptiler.com, attribution to MapTiler and OpenStreetMap).
• Near me: src/components/map/use-near-me.ts reads navigator.geolocation and passes the result to client state only.
• Contact: src/app/about/page.tsx.

Needs a maintainer's check

• That there is no other place user data goes (server logs on Vercel, Supabase auth logs, email sending for password resets and confirmations): I did not cover those.
• Whether you want to promise a response time for access and deletion requests; I did not add one.
• The privacy and data-protection law that applies to your users, if any.

Proof

A new src/app/legal/privacy/page.test.tsx (5 tests) checks that the page names Supabase, Google, Vercel Analytics, Umami and MapTiler, covers the stored data types, says Near me stays in the browser, shows the contact link and the new date, and contains no em dash. npm run lint, npm run typecheck, npm run format:check are clean; npm run test:unit: 652 passed.

Type of change

• Code or fix
• New public place(s)
• New or updated benefit guide
• New or updated resource link
• Docs